Set *_content filter context to WORKER#907
Conversation
The idea is that these filters should *never* be used by the main API server. Making them `LOCAL` too would allow that. So rather than doing this, we prefer making them `WORKER` only and allow any filters to run on workers if the user turns on the proper setting in the API server.
Deploying infrahub-sdk-python with
|
| Latest commit: |
64369aa
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f25b116a.infrahub-sdk-python.pages.dev |
| Branch Preview URL: | https://gma-20260330-content-filter.infrahub-sdk-python.pages.dev |
WalkthroughFour Infrahub template filters— 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## infrahub-develop #907 +/- ##
====================================================
- Coverage 81.09% 81.02% -0.08%
====================================================
Files 121 121
Lines 10592 10628 +36
Branches 1581 1584 +3
====================================================
+ Hits 8590 8611 +21
- Misses 1487 1501 +14
- Partials 515 516 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 10 files with indirect coverage changes 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
tests/unit/sdk/test_infrahub_filters.py (1)
65-67: Broaden this regression to the other three worker-only filters.The PR changes four
INFRAHUB_FILTERSentries, but these assertions only exerciseartifact_content. Parameterizing the trusted/LOCAL-blocked checks overfile_object_content,file_object_content_by_hfid, andfile_object_content_by_idwould keep a typo in any one of those rows from slipping through.Also applies to: 113-117
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/unit/sdk/test_infrahub_filters.py` around lines 65 - 67, Update the unit tests to cover all four INFRAHUB worker-only filters rather than only artifact_content: modify test_not_trusted_when_worker_only (and the similar check around the other test block) to parameterize or iterate over the filter names file_object_content, file_object_content_by_hfid, file_object_content_by_id, and artifact_content and assert fd.trusted is False (and that LOCAL is blocked where applicable) for each; locate the construction using FilterDefinition and ExecutionContext.WORKER (test_not_trusted_when_worker_only) and apply the same parameterized assertions to the other test block that currently checks INFRAHUB_FILTERS entries to ensure each of the four rows is validated.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/docs/python-sdk/reference/templating.mdx`:
- Around line 188-191: The LOCAL description in templating.mdx is out of sync
with the filter availability table (rows for `artifact_content`,
`file_object_content`, `file_object_content_by_hfid`,
`file_object_content_by_id` show unavailable in `LOCAL` but the prose still
claims LOCAL is unrestricted); regenerate the generated docs rather than
manually editing the file by running the docs generator (uv run invoke
docs-generate) to rebuild docs/docs/python-sdk/reference/templating.mdx so the
narrative about `LOCAL` matches the matrix and ensure the `LOCAL` description
text and the table entries for `artifact_content`, `file_object_content`,
`file_object_content_by_hfid`, and `file_object_content_by_id` are consistent.
In `@infrahub_sdk/template/filters.py`:
- Around line 165-168: The listed filters are only labeled with allowed_contexts
but still get registered unconditionally, so enforce the worker-only restriction
by adding a context guard: update _register_client_filters and _set_filters to
skip registering any FilterDefinition whose allowed_contexts does not include
ExecutionContext.WORKER (or alternately wrap those filter callables in a closure
that checks a runtime context and raises if not ExecutionContext.WORKER), and/or
add a final check in Jinja2Template.render to validate the template context
before executing filters; modify the registration logic in
_register_client_filters/_set_filters and/or add the runtime guard inside the
filter wrappers so the filters (e.g., "artifact_content", "file_object_content",
"file_object_content_by_hfid", "file_object_content_by_id") cannot be invoked
unless the active context is ExecutionContext.WORKER.
---
Nitpick comments:
In `@tests/unit/sdk/test_infrahub_filters.py`:
- Around line 65-67: Update the unit tests to cover all four INFRAHUB
worker-only filters rather than only artifact_content: modify
test_not_trusted_when_worker_only (and the similar check around the other test
block) to parameterize or iterate over the filter names file_object_content,
file_object_content_by_hfid, file_object_content_by_id, and artifact_content and
assert fd.trusted is False (and that LOCAL is blocked where applicable) for
each; locate the construction using FilterDefinition and ExecutionContext.WORKER
(test_not_trusted_when_worker_only) and apply the same parameterized assertions
to the other test block that currently checks INFRAHUB_FILTERS entries to ensure
each of the four rows is validated.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5f0bd051-b0cd-4e3b-84f1-56d11406ee22
📒 Files selected for processing (3)
docs/docs/python-sdk/reference/templating.mdxinfrahub_sdk/template/filters.pytests/unit/sdk/test_infrahub_filters.py
Why & What
The idea is that these filters should never be used by the main API server. Making them
LOCALtoo would allow that. So rather than doing this, we prefer making themWORKERonly and allow any filters to run on workers if the user turns on the proper setting in the API server.Related to opsmill/infrahub#8705
Following #904
Checklist
Summary by CodeRabbit
Documentation
Bug Fixes
artifact_content,file_object_content,file_object_content_by_hfid, andfile_object_content_by_idfilters to WORKER execution context; no longer available in LOCAL context.